Many devices common to everyday use derive much of their utility from the manner in which they interact with users and the manner in which they implement their function. Users have become quite accustomed to intelligent machines and appliances. Such machines and appliances are often noted for their ease of use and versatility. Increasingly, a programmable digital system underlies this ease of use and functional capability. For example, consider a modern microwave oven. The microwave oven typically has numerous options for heating, defrosting and cooking, and the like. Numerous combinations of cooking time, power level, and various sensor outputs implement the many cooking routines. Microwave ovens often have sophisticated tables on a panel, where the user merely indicates what type of food is within the oven, and what action is desired (e.g., roast medium, well done, etc.) and the oven does the rest. With such a device, there is no need to be aware of power levels, cooking time, or any other such control.
An embedded digital processing system implements the above features. These systems are referred to as embedded because, unlike some other digital systems, they are not general purpose. An embedded digital processing system has a specific function with specialized software code. These systems are not usually designed to be reprogrammable. They are not usually designed to be interchangeable. Embedded digital processing systems are considered as an integral part of the device in which they are included.
Embedded digital processing systems, or simply, embedded systems, are designed to implement a specific function using specially designed software code. Within more complex devices, there may be several embedded systems, with each system implementing a specific function. In an automobile, for example, there are typically several embedded systems. Each of these systems implement a specific function and interact with the user in a specific way, as with, for example, an automatic speed control, automatic climate control, anti theft system, etc. As modern devices increase in functionality and sophistication, even the most inexpensive device or appliance will include one or more embedded systems to enhance the interface with the user or to accomplish more elaborate functions. Hence, it becomes important to reduce the cost of these embedded systems.
Prior Art FIG. 1 shows a typical prior art embedded system 100. System 100 includes a read only memory (ROM) 102, a ROM 103, random access memory (RAM) 104, and an input output (IO) block 106, each coupled to a processor 105 via a bus 107. Processor 105 communicates with the external circuitry of the device through the coupled IO block 106. ROMs 102 and 103, RAM 104, processor 105, and IO block 106 are each mounted on circuit board 101.
Upon initial power up (e.g., when the device is turned on), startup software located in ROM 103 initializes the software environment of system 100. The startup software functions by setting up the software workspace for processor 105. This work space environment includes the data structures and data objects needed to execute the main program. The data structures include program constants, program variables, heaps, stacks, and the like. While many of these data structures reside in ROM 102 and ROM 103 and thus do not require a set up, certain data structures (e.g., variables, heaps, stacks, and the like) are set up in RAM 104. This is due to the fact that these areas are written to by processor 105 as it executes the main program.
Once the operating environment has been properly set up, processor 105 runs the main program code, implementing the functions as dictated. The main program code coordinates and drives the actions of system 100 in response to inputs and outputs received and sent via IO block 106. The variables, heaps, and other data structures remain in RAM 104, while the operating code runs from ROM 102 and ROM 103. The system continues to function within this environment until power off. Hence, the functionality and the features of the device containing system 100 are dictated by the functionality and features of the main program code and the software operating environment.
Prior Art FIG. 2 shows a memory map 200 of the software of system 100. Memory map 200 diagrams the relationship between the software as designed on the development platform (e.g., a work station at a manufacturing facility), the software on system 100 at power up, and the software on system 100 after initialization. Memory map 200 portrays the software in each of the above situations in columns. The software on the development platform is the first column, the software on system 100 at power up is the second column, and the software on system 100 after initialization is the third column. In each of the columns the contents of RAM and the contents of ROM is shown. The development column shows the "intended" contents of RAM and ROM, since while in development on a workstation or other such system, the actual physical location of the software is irrelevant. The power up column shows the actual physical contents of RAM 104 and ROMs 102 and 103. ROMs 102 and 103 are both 256 KB ROMs combined through addressing into a single 512 KB address space. The after initialization column, in a similar manner, shows the contents of RAM 104 and ROMs 102 and 103.
While the software for system 100 (hereafter system software) is being developed, the intended location and intended size of the system software is carefully tracked and managed. As the development process proceeds, that portion of the system software intended to fit within RAM 104 needs to be within 128 KB (e.g., the size of RAM 104) when development and debugging is complete. This portion comprises the read write (RW) section. Likewise, that portion of system software intended to fit within ROMs 102 and 103 needs to be within 512 KB. This portion comprises the read only (RO) section of the system software. Hence, when development is complete and the device including system 100 is ready for manufacture, the finalized RAM contents and the finalized ROM contents are mapped into the 512 KB ROM address space of ROMs 102 and 103, as shown by arrows 201 and 202.
As described above, at system start up, start up software within the RO section sets up the workspace for system 100. First, the start up software copies the RW section to RAM address space. This is shown by arrows 203. The start up software copies the "image" of the zerovars and initvars to RAM address space. Zerovars are those variables which must initialize to zero. Initvars are those variables which initialize to specific non-trivial values. The zerovars and the initvars are referred to as images due to the fact that they are identical copies of their respective states in RAM address space after initialization.
After copying the zerovars and initvars images, the start up software sets up the variable workspace. The variable workspace comprises the stack, heap, and vars sections. In this manner, the start up software sets up the operating environment. Subsequently, processor 105 runs the main program code from the RO section.
There is a problem, however, in the fact that a large amount of ROM address space is used merely to store images of data which is completely unused after initialization. After the start up program copies the zerovars and initvars images to RAM address space, the large amount of ROM address space is unused during runtime. Additionally, due to the fact that RO section code and the additional zerovars and initvars images cumulatively add up to more than 256 KB, system 100 needs to include two ROMs (e.g., ROM 102 and ROM 103) as opposed to one. Even though a majority of the second ROM is space unused during runtime, its added cost and complexity must be included within system 100. Alternatively, if a single 512 KB ROM where used, the total cost of system 100 is greater than necessary, considering the ROM space unused during runtime.
Thus, what is required is a solution which eliminates wasted address space from embedded systems. The required solution should reduce the amount of ROM space required for storing runtime environment information. The required solution should utilize ROM space more efficiently, to reduce the cost of embedded systems and to provide greater functionality to main program code. The present invention provides this required solution.